Content Security Policy (CSP): Een Uitgebreide Gids voor XSS-Preventie

In het huidige digitale landschap is webbeveiliging van cruciaal belang. Cross-Site Scripting (XSS)-aanvallen blijven een veelvoorkomende en gevaarlijke bedreiging voor webapplicaties wereldwijd. Content Security Policy (CSP) is een krachtige HTTP-responskop die een extra beveiligingslaag biedt en helpt het risico op XSS-kwetsbaarheden te verminderen. Deze gids biedt een uitgebreid overzicht van CSP, de implementatie ervan en de beste praktijken om uw webapplicaties te beschermen tegen XSS-aanvallen.

Wat is Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) is een type injectie-aanval waarbij kwaadaardige scripts worden geïnjecteerd in anderszins onschadelijke en vertrouwde websites. XSS-aanvallen vinden plaats wanneer een aanvaller een webapplicatie gebruikt om kwaadaardige code, meestal in de vorm van een browser-side script, naar een andere eindgebruiker te sturen. Fouten die deze aanvallen mogelijk maken, zijn wijdverbreid en komen overal voor waar een webapplicatie invoer van een gebruiker gebruikt binnen de output die het genereert zonder deze te valideren of te coderen.

Er zijn drie hoofdtypen XSS-aanvallen:

• Opgeslagen (Persistent) XSS: Het kwaadaardige script wordt permanent opgeslagen op de doelserver (bijvoorbeeld in een database, berichtenforum, bezoekerslogboek, opmerkingenveld, enz.). Wanneer een gebruiker de getroffen pagina bezoekt, wordt het opgeslagen script uitgevoerd.
• Weerkaatste (Niet-Persistent) XSS: Het kwaadaardige script wordt weerkaatst vanaf de webserver, bijvoorbeeld in een foutmelding, zoekresultaat of een andere reactie die een deel of alle invoer bevat die naar de server is verzonden als onderdeel van het verzoek. De gebruiker moet worden misleid om op een kwaadaardige link te klikken of een formulier in te dienen dat het kwaadaardige script bevat.
• DOM-gebaseerde XSS: De kwetsbaarheid bestaat in de client-side code zelf. Het kwaadaardige script wordt uitgevoerd omdat de DOM-omgeving van de browser wordt gemanipuleerd om het script van de aanvaller op te nemen.

XSS-aanvallen kunnen ernstige gevolgen hebben, waaronder:

• Het stelen van gebruikersreferenties (cookies, sessietokens).
• Het ontsieren van websites.
• Het omleiden van gebruikers naar kwaadaardige sites.
• Het installeren van malware.
• Het verkrijgen van ongeoorloofde toegang tot gevoelige gegevens.

Wat is Content Security Policy (CSP)?

Content Security Policy (CSP) is een extra beveiligingslaag die helpt bij het detecteren en verminderen van bepaalde soorten aanvallen, waaronder Cross-Site Scripting (XSS) en data-injectie-aanvallen. CSP wordt geïmplementeerd met behulp van een HTTP-responskop waarmee u de resources (bijvoorbeeld scripts, stylesheets, afbeeldingen, lettertypen, frames) kunt controleren die de browser mag laden voor een specifieke pagina. Door een strikte CSP te definiëren, kunt u het aanvalsoppervlak van uw webapplicatie aanzienlijk verkleinen en het voor aanvallers moeilijker maken om kwaadaardige code te injecteren.

CSP werkt door een whitelist te definiëren van bronnen waaruit de browser resources mag laden. Elke resource die wordt geladen vanaf een bron die niet expliciet is toegestaan in de CSP, wordt door de browser geblokkeerd. Dit voorkomt de uitvoering van ongeautoriseerde scripts en vermindert het risico op XSS-aanvallen.

Hoe CSP Werkt: Directives en Bronnen

CSP wordt geconfigureerd met behulp van een reeks directives, die elk een beleid specificeren voor een bepaald type resource. Elke directive bestaat uit een naam, gevolgd door een lijst met toegestane bronnen. Hier zijn enkele van de meest gebruikte CSP-directives:

• `default-src`: Specificeert het standaardbeleid voor het ophalen van resources als er geen andere resourcespecifieke directives aanwezig zijn.
• `script-src`: Specificeert de toegestane bronnen voor JavaScript-code.
• `style-src`: Specificeert de toegestane bronnen voor stylesheets (CSS).
• `img-src`: Specificeert de toegestane bronnen voor afbeeldingen.
• `font-src`: Specificeert de toegestane bronnen voor lettertypen.
• `connect-src`: Specificeert de toegestane bronnen voor het maken van netwerkverzoeken (bijvoorbeeld AJAX, WebSockets).
• `media-src`: Specificeert de toegestane bronnen voor het laden van video- en audio-resources.
• `object-src`: Specificeert de toegestane bronnen voor plugins, zoals Flash.
• `frame-src`: Specificeert de toegestane bronnen voor het insluiten van frames (iframes).
• `base-uri`: Beperkt de URL's die kunnen worden gebruikt in het <base>-element van een document.
• `form-action`: Beperkt de URL's waarnaar formulieren kunnen worden ingediend.
• `upgrade-insecure-requests`: Instrueert browsers om onveilige (HTTP) verzoeken automatisch te upgraden naar veilige (HTTPS) verzoeken.
• `block-all-mixed-content`: Voorkomt dat de browser resources laadt met behulp van HTTP wanneer de pagina via HTTPS wordt geladen.
• `report-uri`: Specificeert een URL waarnaar de browser rapporten van CSP-overtredingen moet verzenden. Afgekeurd ten gunste van `report-to`.
• `report-to`: Specificeert een benoemd eindpunt waarnaar de browser rapporten van CSP-overtredingen moet verzenden.

Veelgebruikte bronwaarden zijn onder meer:

• `*`: Staat resources van elke bron toe (niet aanbevolen voor productieomgevingen).
• `'self'`: Staat resources toe van dezelfde origin (schema, host en poort) als het beveiligde document.
• `'none'`: Staat het laden van resources van een bron niet toe.
• `data:`: Staat het laden van resources via het `data:` schema toe (bijvoorbeeld inline afbeeldingen).
• `'unsafe-inline'`: Staat het gebruik van inline JavaScript en CSS toe (sterk ontraden).
• `'unsafe-eval'`: Staat het gebruik van `eval()` en vergelijkbare functies toe (sterk ontraden).
• `'strict-dynamic'`: Specificeert dat het vertrouwen dat expliciet wordt gegeven aan een script dat in de opmaak aanwezig is, door het te vergezellen van een nonce of hash, wordt doorgegeven aan alle scripts die door dat rootscript worden geladen.
• `'nonce-'`: Staat scripts of stijlen met een overeenkomend nonce-kenmerk toe.
• `'sha256-'`, `'sha384-'`, `'sha512-'`: Staat scripts of stijlen met een overeenkomende SHA-hash toe.
• `https://example.com`: Staat resources van een specifiek domein toe.

CSP Implementeren

CSP kan op twee manieren worden geïmplementeerd:

1. HTTP Header: De voorkeursmethode is om uw webserver te configureren om de `Content-Security-Policy` HTTP-responskop te verzenden. Hiermee kunt u de CSP voor elke pagina of resource op uw website definiëren.
2. <meta> Tag: CSP kan ook worden gedefinieerd met behulp van een <meta>-tag in het <head>-gedeelte van uw HTML-document. Deze methode is echter minder flexibel en heeft beperkingen in vergelijking met het gebruik van de HTTP-header. De directives `frame-ancestors`, `sandbox` en `report-uri` kunnen bijvoorbeeld niet worden gebruikt in HTML-meta-tags.

De HTTP-Header Gebruiken

Om CSP te implementeren met behulp van de HTTP-header, moet u uw webserver configureren om de `Content-Security-Policy`-header in zijn antwoorden op te nemen. De specifieke configuratiestappen variëren afhankelijk van de webserver die u gebruikt.

Hier zijn voorbeelden voor veelgebruikte webservers:

• Apache: Voeg de volgende regel toe aan uw `.htaccess`-bestand of virtual host-configuratie:

            Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;"
            

              
                Copy
              
            
          

• Nginx: Voeg de volgende regel toe aan uw server block-configuratie:

            add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;";
            

              
                Copy
              
            
          

• Node.js (Express): Gebruik middleware om de header in te stellen:

            app.use(function(req, res, next) {
  res.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;");
  next();
});
            

              
                Copy
              
            
          

De <meta> Tag Gebruiken

Om CSP te implementeren met behulp van de <meta>-tag, voegt u de volgende tag toe aan het <head>-gedeelte van uw HTML-document:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;">
            

              
                Copy
              
            
          

Belangrijke overwegingen:

• Het attribuut `http-equiv` moet worden ingesteld op "Content-Security-Policy".
• Het attribuut `content` bevat de CSP-directives.
• Onthoud de beperkingen van het gebruik van <meta>-tags, zoals eerder vermeld.

CSP-Voorbeelden

Hier zijn verschillende CSP-voorbeelden met uitleg:

1. Basis CSP:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

Dit beleid staat alleen resources van dezelfde origin toe.

2. Scripts toestaan van een specifiek domein:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com;
            

              
                Copy
              
            
          

Dit beleid staat resources van dezelfde origin en scripts van `https://example.com` toe.

3. Stijlen toestaan van een CDN:

            Content-Security-Policy: default-src 'self'; style-src 'self' https://cdn.example.com;
            

              
                Copy
              
            
          

Dit beleid staat resources van dezelfde origin en stijlen van `https://cdn.example.com` toe.

4. Afbeeldingen toestaan van elke bron:

            Content-Security-Policy: default-src 'self'; img-src *;
            

              
                Copy
              
            
          

Dit beleid staat resources van dezelfde origin en afbeeldingen van elke bron toe (niet aanbevolen voor productie).

5. CSP-overtredingen rapporteren:

            Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint;
            

              
                Copy
              
            
          

Dit beleid staat resources van dezelfde origin toe en stuurt overtredingsrapporten naar `/csp-report-endpoint`. Het wordt aanbevolen om `report-to` te gebruiken in plaats van `report-uri`.

6. Gebruik `report-to` en `report-uri` samen voor compatibiliteit:

            Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint; report-to csp-endpoint;
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint; report-to csp-endpoint;
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/csp-report-endpoint"}]}
            

              
                Copy
              
            
          

Dit voorbeeld toont hoe u zowel een `report-uri` (voor oudere browsers) als een `report-to`-eindpunt instelt, samen met het configureren van de `Report-To`-header zelf. Zorg ervoor dat uw server de `Report-To`-header correct afhandelt en de `group`, `max_age` en `endpoints` correct instelt.

7. Nonces gebruiken voor inline scripts:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3Str1nG';
            

              
                Copy
              
            
          

Dit beleid staat resources van dezelfde origin en inline scripts met het overeenkomende nonce-kenmerk toe.

            <script nonce="rAnd0mN0nc3Str1nG">
  // Uw inline scriptcode hier
</script>
            

              
                Copy
              
            
          

CSP in Report-Only-modus

CSP kan in twee modi worden geïmplementeerd:

• Afgedwongen modus: De browser blokkeert resources die de CSP overtreden.
• Report-Only-modus: De browser rapporteert CSP-overtredingen aan een specifiek eindpunt zonder resources te blokkeren.

De Report-Only-modus is handig voor het testen en verfijnen van uw CSP voordat u deze afdwingt. Om de Report-Only-modus in te schakelen, gebruikt u de `Content-Security-Policy-Report-Only` HTTP-header in plaats van de `Content-Security-Policy`-header.

Voorbeeld:

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;
            

              
                Copy
              
            
          

Deze configuratie verzendt rapporten naar `/csp-report-endpoint` zonder resources te blokkeren.

Beste Praktijken voor het Implementeren van CSP

Hier zijn enkele beste praktijken voor het effectief implementeren van CSP:

1. Begin met een strikt beleid: Begin met een restrictief beleid dat alleen resources van dezelfde origin toestaat en versoepel dit geleidelijk indien nodig.
2. Gebruik Nonces of Hashes voor Inline Scripts en Stijlen: Vermijd het gebruik van `'unsafe-inline'` en gebruik nonces of hashes om specifieke inline scripts en stijlen toe te staan.
3. Vermijd `'unsafe-eval'`: Vermijd indien mogelijk het gebruik van `'unsafe-eval'` omdat dit beveiligingsrisico's met zich mee kan brengen. Overweeg alternatieve benaderingen voor dynamische code-uitvoering.
4. Gebruik HTTPS: Zorg ervoor dat alle resources via HTTPS worden geladen om man-in-the-middle-aanvallen te voorkomen. Gebruik de directive `upgrade-insecure-requests` om onveilige verzoeken automatisch te upgraden.
5. Monitor CSP-overtredingen: Stel een rapporterings-eindpunt in om CSP-overtredingen te controleren en potentiële beveiligingsproblemen te identificeren.
6. Test uw CSP grondig: Test uw CSP in verschillende browsers en omgevingen om ervoor te zorgen dat deze naar verwachting werkt.
7. Herhaal en verfijn: CSP-implementatie is een iteratief proces. Monitor en verfijn uw CSP continu naarmate uw applicatie evolueert.
8. Overweeg de `strict-dynamic` directive: Gebruik `strict-dynamic` om de complexiteit van uw CSP te verminderen door vertrouwen te propageren naar scripts die worden geladen door vertrouwde scripts.

Hulpprogramma's voor CSP

Verschillende tools kunnen u helpen bij het genereren, testen en controleren van CSP:

• CSP-Generatoren: Online tools die CSP-directives genereren op basis van de resources van uw website.
• Browser Developer Tools: De meeste moderne browsers bieden ontwikkelaarstools die u kunnen helpen bij het analyseren van CSP-overtredingen.
• CSP-Monitoring Services: Services die CSP-overtredingsrapporten verzamelen en analyseren.

CSP en Frameworks/Libraries

Bij het gebruik van frameworks en libraries is het belangrijk om CSP correct te configureren om compatibiliteit te garanderen en beveiligingsproblemen te voorkomen. Hier zijn enkele overwegingen:

• JavaScript Frameworks (bijv. React, Angular, Vue.js): Deze frameworks gebruiken vaak inline stijlen of dynamische codegeneratie, waarvoor mogelijk speciale CSP-configuraties nodig zijn (bijv. nonces, hashes, `'unsafe-eval'`).
• CSS Frameworks (bijv. Bootstrap, Tailwind CSS): Deze frameworks kunnen inline stijlen of externe stylesheets gebruiken, die in uw CSP moeten worden toegestaan.
• Third-Party Libraries: Zorg ervoor dat alle third-party libraries die u gebruikt compatibel zijn met uw CSP en geen beveiligingsproblemen introduceren.

CSP en CDNs (Content Delivery Networks)

CDNs worden vaak gebruikt om statische assets te hosten, zoals JavaScript-bestanden, CSS-stylesheets en afbeeldingen. Om resources van CDNs in uw CSP toe te staan, moet u expliciet de CDN-domeinen op de whitelist zetten.

Voorbeeld:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' https://cdnjs.cloudflare.com;
            

              
                Copy
              
            
          

Dit beleid staat scripts van jsDelivr en stijlen van Cloudflare's cdnjs toe.

Veelvoorkomende CSP-fouten om te vermijden

Hier zijn enkele veelvoorkomende CSP-fouten die u moet vermijden:

• `*` gebruiken als een bron: Resources van elke bron toestaan, kan de voordelen van CSP tenietdoen.
• `'unsafe-inline'` en `'unsafe-eval'` gebruiken zonder rechtvaardiging: Deze directives kunnen beveiligingsrisico's met zich meebrengen en moeten, indien mogelijk, worden vermeden.
• CSP-overtredingen niet controleren: Het niet controleren van CSP-overtredingen kan voorkomen dat u beveiligingsproblemen identificeert en aanpakt.
• CSP niet grondig testen: Onvoldoende testen kan leiden tot onverwacht gedrag en beveiligingskwetsbaarheden.
• Nonces en hashes onjuist configureren: Onjuist geconfigureerde nonces en hashes kunnen voorkomen dat legitieme scripts en stijlen worden geladen.

Geavanceerde CSP-concepten

Naast de basisprincipes kunnen verschillende geavanceerde CSP-concepten uw webbeveiliging verder verbeteren:

• `frame-ancestors` Directive: Specificeert de toegestane ouders die een frame (iframe) in uw pagina mogen insluiten. Beschermt tegen clickjacking-aanvallen.
• `sandbox` Directive: Maakt een sandbox mogelijk voor de aangevraagde resource en past beperkingen toe op de mogelijkheden (bijvoorbeeld het voorkomen van scriptuitvoering, het indienen van formulieren).
• `require-sri-for` Directive: Vereist Subresource Integrity (SRI) voor scripts of stijlen die worden geladen van externe bronnen. SRI zorgt ervoor dat er niet met de bestanden is geknoeid.
• Trusted Types API: Helpt DOM-gebaseerde XSS te voorkomen door typeveiligheid af te dwingen op DOM-sinks.

De Toekomst van CSP

CSP evolueert voortdurend om nieuwe beveiligingsuitdagingen aan te pakken. Toekomstige ontwikkelingen kunnen het volgende omvatten:

• Verbeterde browserondersteuning: Voortdurende verbeteringen in browserondersteuning voor CSP-functies.
• Nieuwe directives en functies: Introductie van nieuwe directives en functies om opkomende beveiligingsbedreigingen aan te pakken.
• Integratie met beveiligingstools: Diepere integratie met beveiligingstools en -platforms om CSP-beheer en -monitoring te automatiseren.

Conclusie

Content Security Policy (CSP) is een krachtig hulpmiddel voor het beperken van XSS-aanvallen en het verbeteren van webbeveiliging. Door een strikte CSP te definiëren, kunt u het aanvalsoppervlak van uw webapplicatie aanzienlijk verkleinen en uw gebruikers beschermen tegen kwaadaardige code. Het effectief implementeren van CSP vereist zorgvuldige planning, grondig testen en continu monitoren. Door de beste praktijken in deze gids te volgen, kunt u CSP gebruiken om de beveiligingshouding van uw webapplicaties te verbeteren en uw online aanwezigheid in het wereldwijde digitale ecosysteem te beschermen.

Vergeet niet om uw CSP regelmatig te bekijken en bij te werken om u aan te passen aan evoluerende beveiligingsbedreigingen en ervoor te zorgen dat uw webapplicaties beschermd blijven.